After defining some (or all) of your primary and
secondary sites, you can begin to plan the site infrastructure and
services at each site. The major tasks involved in site planning include
determining the site systems to deploy, sizing the hardware for each
site system, and determining the boundaries and security mode for the
site.
Site Servers and Site Systems Planning
The server infrastructure
is the foundation of your site. The following sections present key
issues to consider as you decide how to distribute system roles among
servers as well as specifications for server hardware.
Deploying Site System Roles
The minimum
server requirement for a Configuration Manager site is a single site
server. The site server can be configured for all the site system roles
deployed at your site, or you can assign some roles to additional
servers. Here are some reasons for assigning site system roles to
servers other than the site server:
Network topology— For sites that span WAN links, you will generally want to make distribution points available at each physical location.
Security—
You may want to move client-facing roles such as the management point
(MP), distribution point (DP), and software update point (SUP) off the
site server to prevent clients from accessing the site server directly.
You will definitely want to do this if you support Internet clients, in
which case you would deploy those servers accessible from the Internet
in a DMZ (demilitarized zone).
Scalability—
For large sites you may want to distribute the computing load between
multiple systems. For very large sites, you may need to use Network Load
Balancing (NLB) clusters with certain site systems. You can also configure the management point and server
locator point to use a replica of the site database. Using a SQL
replica distributes the load across multiple servers, but introduces
replication latency, which increases the time for updates to become
available to client systems.
Management—
In general, you will get sufficient performance if you install SQL
Server on your primary site servers and keep the Configuration Manager
database local on the site server, provided the site server has adequate
hardware resources. Many organizations have SQL database servers
already deployed and supported by database administrators. In this case,
it may make sense to move the site database to one of these servers,
particularly if that will enable you to take advantage of SQL Server
clustering and use 64-bit SQL Server editions.
SQL
Server is the only site system that supports failover clustering, and
it’s the only ConfigMgr role that Microsoft recommends running on the
64-bit versions of Windows. Configuration Manager is a
database-intensive application. If the database is not on the site
server, it is essential to have very good connectivity between the site
server and the SQL Server system.
System Requirements
Table 1 displays the minimum requirements for Configuration Manager 2007 site systems.
Table 1. Site System Components and Requirements
| Component | Requirement |
|---|
| Processor | 733MHz Pentium III minimum (2.0 GHz or faster recommended). |
| RAM | 256MB minimum (1,024MB or more recommended). |
| Free disk space | 5GB minimum formatted with the NTFS file system (15GB or more free recommended if using Operating System Deployment [OSD]). |
| Operating system | Supported systems include the following:
Windows Server 2003 Standard or Enterprise Edition Service Pack 2. Both 64-bit and Release 2 (R2) versions are supported. Windows
Server 2003 Storage Server Edition SP 2 or higher and Windows Server
2003 Web Edition SP 2 or higher are supported for the distribution point
and the Configuration Manager console only. Client
operating systems (Windows XP Service Pack 2 or higher, excluding
consumer editions) are supported for the branch distribution point and
ConfigMgr console only. All
site system roles are supported on all versions of Windows Server 2008
except for Server Core. Windows Server 2008 support requires
Configuration Manager 2007 SP 1.
|
As
with any Windows installation, Microsoft only supports hardware
components listed on the Windows Hardware Compatibility List (HCL). The
HCL for each Windows version is located at http://www.microsoft.com/whdc/hcl/default.mspx.
For maximum supportability, it is best to use hardware bearing the
Windows Server Hardware logo. Information about Windows logo certified
hardware is available in the Windows Server catalog, at http://go.microsoft.com/fwlink/?LinkID=80785.
Other installation requirements include the following:
All site
systems must be belong to a Windows 2000, Windows 2003, or Windows
Server 2008 Active Directory domain. With the exception of the site
database server, Microsoft does not support installing Configuration
Manager 2007 site servers or any other site systems on a Windows Server
cluster instance. Computers that are physical nodes of a Windows Server
cluster instance can be managed as Configuration Manager 2007 clients.
Using
a Storage Area Network (SAN) is supported as long as a supported
Windows server is attached directly to the volume hosted by the SAN.
Install the site
database on the default instance or a named instance of SQL Server,
using SQL Server 2005 Service Pack 2 or greater. You can also configure
the instance used to host the site database as a SQL Server failover
cluster instance.
Configuration Manager 2007 R2 introduces three new site system roles:
The Client Status
Reporting Host System role is supported on all versions of Windows
Server 2003 SP 1 and above, Windows Server 2008, and on client operating
systems (including Windows XP Service Pack 2 or higher, excluding
consumer editions). The Reporting Services Point and Distribution Point
for Application Virtualization roles are supported on Standard and
Enterprise editions of Windows Server 2003 (SP 2 or higher) and Windows
Server 2008. The Reporting Services Point role is also supported on the
Datacenter editions of Windows Server.
The placement of
distribution points (DPs) is especially important in site planning. DPs
are generally implemented in the following manner:
One or more
standard (unprotected) DPs at the primary network location of the site.
Additional distribution points will provide load balancing and
redundancy. Clients at the central location and clients not assigned to a
protected distribution point will use these unprotected DPs.
Protected distribution points at remote locations with adequate server infrastructure.
Branch
DPs at smaller locations without server infrastructure. You may also
choose to use a branch DP to take advantage of Background Intelligent
Transfer Service (BITS) transfers across the WAN and on-demand package
deployment.
Both distribution
points and software update points may require substantial storage.
Storage requirements for distribution points depend on the number and
size of software packages and OS images they host.
Heavily used
distribution points and software update points will handle a large
amount of network traffic; you will want to provision them with the
fastest network card your network infrastructure supports.
|
Distribution
points and software update points can be installed on NAS (Network
Attached Storage) devices running the required Windows Server versions.
You can also install these system roles on servers using directly
connected SAN storage. Enterprise storage vendors offer replication
technology that may provide advantages over Configuration Manager
package replication or Windows Software Update Service (WSUS)
replication, although integrating other replication technologies with
Configuration Manager may present some challenges.
You can use third-party
replication to copy content to a standard Windows file share and use a
Universal Naming Convention (UNC) path to run programs from the share.
This model loses some advantages of Configuration Manager software
distribution, such as the download-and-run capability and the use of
BITS.
When
distributing packages to branch distribution points, you can specify the
option that the administrator manually copies this package to branch
distribution points for those packages that will be copied outside of
the ConfigMgr distribution process. Once again, the BITS functionality
and download-and-run option are not available for branch distribution
points. It is likely that Microsoft will extend this option (that the
administrator manually copy this package) to standard distribution
points in future releases of Configuration Manager. Using third-party
replication to fully deploy packages to child sites also requires the
use of courier sender.
|
Hardware Sizing and Configuration
The minimum/published
(“box”) hardware specs are far below what you should consider for
anything more than a small lab environment. A typical site server for a
moderately sized site with 1,000–5,000 clients might have two to four
quad core processors and 4GB–8GB of RAM. Because Configuration Manager
2007 is a 32-bit application, Microsoft recommends running it on a
32-bit version of Windows Server for best performance. SQL Server fully
supports 64-bit computing, and performs best on a 64-bit platform.
If you use System
Center Operations Manager (OpsMgr) to monitor your environment and are
considering deploying Configuration Manager on a 64-bit server OS, you
should review the information presented at http://wmug.co.uk/blogs/cliffs_blog/archive/2009/02/14/configmgr-monitoring-configmgr-2007-with-operations-manager-2007-in-a-64-bit-environment.aspx. The
issue Cliff Hobbs discusses is that the ConfigMgr client is 32-bit
only, so its performance counters are only captured by the 32-bit OpsMgr
agent. However, because the OS is 64 bit, this means performance
counters are only captured by a 64-bit OpsMgr agent—and you can’t
install both versions of the agent on a single system.
Similar considerations
may apply to other monitoring applications. ConfigMgr 2007 Service Pack 2
will add native 64-bit performance counters to the ConfigMgr client, so
it can be monitored along with the OS and other 64-bit applications
using a 64-bit Operations Manager agent.
Configuration Manager is
an I/O-intensive application, and it will benefit from the fastest disk
subsystem you can provide. Here are some points to keep in mind:
The volume on
which you install Configuration Manager and the volume containing the
site database will experience the heaviest disk utilization. For best
performance using local storage, install Configuration Manager on a
separate array from the OS and other applications, using a separate
controller if available.
If
you install SQL Server locally on the site server, you should also
consider separate disk arrays for the SQL Server application and the SQL
log files. Corporate standards may specify the RAID (redundant array of
independent disks) levels for the OS and application partitions.
Table 2 lists a representative storage configuration for an all-in-one site server.
Table 2. Suggested Storage Configurations for an All-in-One Site Server
| Purpose | Partitions | Physical Storage |
|---|
| OS | C: | RAID 1 (mirrored) |
| Configuration Manager | E: | RAID 5 (striping with parity) |
| SQL Server | F: | RAID 5 |
| SQL log files | G: | |
| WSUS and so on | H: | |
| Paging File | X: | |
Microsoft describes the different RAID types in an article at http://technet2.microsoft.com/windowsserver/en/library/cb871b6c-8ce7-4eb7-9aba-52b36e31d2a11033.mspx?mfr=true.
For optimal performance, implement all RAID arrays at the hardware
level. For details on implementing hardware-based RAID, consult the
documentation from your hardware vendor. If using SAN storage, you
should install Configuration Manager on a dedicated Logical Unit Number
(LUN), if available.
Note: About Deploying Site Systems on Virtual Machines
All Configuration
Manager 2007 site server roles are supported on virtual machines running
the appropriate Windows Server versions as guest operating systems on a
Microsoft Virtual Server 2005 R2 host with or without SP 1. Hyper-V is
also supported, and Cliff Hobbs has an excellent article on migrating
your virtual machines to Hyper-V at http://wmug.co.uk/blogs/cliffs_blog/archive/2009/02/10/hyper-v-how-to-migrate-vms-to-hyper-v.aspx.
It is important to
review Microsoft’s support policy before deploying any ConfigMgr site
system roles to Windows Server systems running on other virtualization
platforms such as VMware. There is anecdotal evidence that Configuration
Manager has been successfully deployed on VMware ESX; however,
Microsoft does not guarantee to fully support software running on any
non-Microsoft virtualization technology. You should read and consider
Microsoft’s “Support policy for Microsoft software running in
non-Microsoft hardware virtualization software” (http://support.microsoft.com/kb/897615)
before deploying any Microsoft software on non-Microsoft virtualization
platforms. Virtualization platforms listed in the Server Virtualization
Validation Program (SVVP) are supported for all site system roles,
subject to the terms of that program. For more information about SVVP,
see http://go.microsoft.com/fwlink/?LinkId=134672.
In general, demanding
applications such as a site server or a SQL Server database for a large
primary site are not good candidates for virtualization. In this
context, a site with more than 1,000 clients reporting to it, including
clients at child sites, is a poor candidate for a virtualized site
server. The authors have seen instances where even a virtualized site
server at a site with a few hundred clients may present problems.
Disk
defragmentation should be run on a regular basis. It is also important
to use a consistent SMS_Def.mof file throughout your hierarchy to allow
multithreaded processing of hardware inventory data.
For a detailed discussion of choosing, tuning, and benchmarking hardware, check the following references:
|
The Capacity Planner provides a set of macro-driven Excel
worksheets whose objectives include the following:
Suggesting edge locations for SCCM Server and SCCM Component Servers. Edge locations are typically the lowest tier sites. Suggesting hardware for SCCM Server and SCCM Component Servers. The
tool allows you to enter scenarios about your site hierarchy and
assumptions about each site, and it outputs hardware recommendations and
other capacity-related information. You can easily try various what-if
scenarios, such as replacing a distribution point with a branch
distribution point or using a replicated SQL Server database for your
management point. Sample scenarios are included that let you play with
many possible configurations.
The current version of the tool, available at http://www.tondtware.com/downloads.html,
comes with a disclaimer that it is a work in progress. No capacity
planning tool can take every factor of your environment and usage into
account. The results this tool has given seem pretty realistic, though,
and it is a great way to explore various possible configurations. Like
SMSMap, this is definitely a tool to try.
|
Antivirus Scanning
To avoid performance
degradation, establish appropriate virus-scanning exclusions for all
inboxes on the site server. The individual inboxes are subfolders of the
inboxes folder (%ProgramFiles%\Microsoft
Configuration Manager\Inboxes by default) with .box folder names. Some
enterprise antivirus products are capable of applying exclusions
selectively to certain processes. You should also consider
virus-scanning exclusions for the following areas:
All server and client log files
The client cache folders and WMI (Windows Management Instrumentation) folders
All SQL Server databases and transaction logs
Site backup files and volume shadow copy files
Planning for Very Large Sites
Very large sites, especially those with 25,000 or more clients, have some special considerations to include in your planning.
Planning Site Boundaries
Configuration Manager clients use site boundaries for two purposes:
It is important to plan and
maintain site boundaries that are appropriate to your network topology
and do not overlap. Overlapping boundaries will cause problems for
Configuration Manager clients.
Automatic site assignment
can have unpredictable results when a client is located within the
boundaries of more than one site. Overlapping boundaries will also cause
problems with software distribution. Clients access content from the
distribution points of the site in which they currently reside; having
conflicting site boundaries can result in the client failing to locate
available content or downloading content from an inappropriate location.
You can specify boundaries by Active Directory (AD) sites, Internet
Protocol (IP) subnets, IP address ranges, or IPv6 prefixes.
Planning for Site Security Modes
Each Configuration
Manager site can be in one of two security modes—native or mixed mode.
Here are some reasons you may choose to use native mode:
Native
mode sites use mutual, certificate-based authentication between site
systems and between clients and servers. Native mode also provides
advanced encryption and signing for secure exchanges. This is the most
secure option for a Configuration Manager site.
Native mode is required for Internet-based client support.
Here are some reasons to choose to use mixed mode:
Native mode
requires a properly implemented Public Key Infrastructure (PKI). PKI
design, testing, and implementation involve a major organizational
investment and require proper planning. Your PKI deployment should take
into account other applications and requirements you may have in
addition to your Configuration Manager requirements.
Mixed
mode sites support SMS 2003 (SP 3 or higher clients), as well as
Windows 2000 clients. Native mode sites do not support these older
clients.
Your organization requires WINS (Windows Internet Name Service) for clients to locate their default management point.
